✅ Qwen Triage finished — view run. See the stage comments in this thread for the result.

✅ Qwen Triage 已完成 —— 查看运行。结果见本线程中的各阶段评论。

Thanks for the PR!

Template looks good ✓ — every section filled in, including a real before/after and the platform table.

Problem: observed, not theoretical, and about as well-evidenced as a fix gets. There is a production incident with measurements (177 wedged processes, ~2.5k failing mkdir/s each, ~67% system time fleet-wide, one host's load average 213 → 12 after the containers were reaped), an strace syscall signature taken from a live wedged process, and a self-contained unshare -m bind-mount reproduction showing the recursive form still pending at 6s / 103% CPU against the single-level form rejecting ENOENT at 0%. I checked the cross-reference too: #11264 is open and does address the container leak itself, so this is genuinely the complementary CLI-side half rather than a duplicate of it.

Direction: aligned. The real defect is that mkdir(..., { recursive: true }) has no retry cap and no backoff, so on a mountpoint that still stats as a directory but rejects creates with ENOENT, the returned promise never settles. That defeats the .catch(() => {}) sitting right beside it — the guard that was supposed to make this best-effort can never run — and the await wedges the housekeeping chain for the remaining life of the process. Turning an intended graceful skip into a permanent hang plus a burned core is squarely a bug, not hardening.

Size: not applicable — packages/cli/src/utils/housekeeping/ is not a core path, and this is a single package. For the record: 17 production lines (14 added + 3 removed) in one file, 38 test lines, 2 files total. Well under every threshold in either tier.

Approach: the scope feels right and I'd have proposed the same thing. I weighed the two alternatives before reading the diff — wrapping the mkdir in a timeout, or pre-statting the parent — and both are worse here. A timeout lets the awaiting chain move on but cannot cancel the retry loop Node is already running, so the CPU cost that made this an incident may well survive it; pre-statting adds code without removing the unbounded retry at all. Dropping recursive: true addresses both symptoms in one line, which is the minimal change for the stated goal. Nothing unrelated rides along in the diff.

One caveat to flag now and detail in the code review: the description justifies one level with "every caller puts lockPath directly in the global qwen dir, whose own parent is $HOME". The first half is exactly right — I verified all three call sites. But the directory this mkdir creates is the global qwen dir itself, and QWEN_HOME can point that somewhere deeper than $HOME/.qwen, so the "parent is $HOME" half is narrower than it reads. Non-blocking, and the failure mode stays graceful — details below.

Risk: no elevated risk signals. Neither changed file matches the revert-correlated path list.

Moving on to code review. 🔍

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 4d54e6a3364a462f046d424120ded6a9ba18f667 · re-run with @qwen-code /triage}

Code review

I traced the change against every consumer rather than taking the description's word for it, since dropping recursive: true is only safe if the directory being created never needs a parent bootstrapped.

The load-bearing claim holds. dirname(opts.lockPath) resolves to the global qwen dir itself for all three call sites, not to a subdirectory of it — so one level is indeed the whole job:

The two hashed marker paths were the ones worth checking — both hash the key into a filename, not into extra directory levels, so neither reaches below qwenDir.

The failure path degrades instead of wedging, on both schedulers. This is what makes the change safe rather than just smaller. If the mkdir now fails, .catch(() => {}) swallows it, tryAcquire hits open(lockPath, 'wx'), gets ENOENT, and rethrows — only EEXIST is converted to false. That throw is caught in both entry points: runPass logs housekeeping pass failed; will retry next cycle and still schedules the next pass, and the non-interactive worker's catch logs and reschedules via NON_INTERACTIVE_FAILURE_RETRY_MS. So the timer chain survives either way, which matches what the PR intends.

One non-blocking note — the "parent is $HOME" half of the justification is narrower than it reads. getGlobalQwenDir() returns Storage.resolvePath(process.env.QWEN_HOME) when that variable is set, falling back to path.join(os.homedir(), QWEN_DIR). So the parent of the directory this mkdir creates is $HOME only in the default layout; with QWEN_HOME=/some/deep/path whose parent chain doesn't exist yet, the old recursive call would have bootstrapped the tree and the new one won't. The Risk section already gestures at this but frames it as a hypothetical future caller passing a deeper lockPath — QWEN_HOME makes the same gap reachable today without any new call site. Worth a wording tweak rather than a code change: the outcome is still the intended graceful skip (logged failure, retry next cycle, chain intact), housekeeping is best-effort cleanup, and I found no other production code that recursively creates the global qwen dir at startup — the only recursive creator is PollingChannelBase, and that's getGlobalQwenDir()/channels, conditional on a polling channel actually running.

The comment block earns its place. Ten lines of comment on a one-line change would normally be too much, but the why here is genuinely non-obvious and load-bearing: without it the next contributor re-adds recursive: true as an obvious-looking robustness improvement and silently reintroduces the hang. The pre-existing comment above it was extended rather than replaced, which is the right call.

Tests are real guards, not decoration. The first new test uses a fresh directory that genuinely doesn't exist, so it pins that dropping recursive didn't lose the create — and asserting stat.mode & 0o077 === 0 instead of an exact mode keeps the 0o700 convention check umask-proof, which is a nice touch. The second iterates every mkdir call and rejects recursive: true; the author demonstrated it fails with a specific matcher message when the option is restored, so it's falsifiable rather than tautological.

Neither test pins the incident itself — a never-settling promise on a deleted bind mount needs root and a mount namespace, which is reasonably out of scope for a unit test. That gap is what the verification line below is for.

No reuse concerns: nothing new is being abstracted, so there's no parallel utility to consolidate.

Test evidence

Update: CI settled after this section was first written, and it settled with the unit suite dead on arrival. The original version of this comment reported the Linux unit job as in progress; the table and the analysis below are the settled state for commit 4d54e6a3364a462f046d424120ded6a9ba18f667. This is an unattended CI run, so I did not build, run, or execute anything from this PR — all of it was read through the API. Of 55 check-runs: 16 success, 2 failure, 34 skipped, and 3 still in progress (the bot's own review-pr and triage orchestration jobs, which run on pull_request_target and are not this PR's CI).

Final CI results for 4d54e6a (auto-updated by the triage finalize job after CI completed):

_{One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。}

Both red checks are runner-side checkout failures, not this PR. They are the same class of failure, and neither reached any of the PR's code:

• Classify PR failed in its Checkout trusted CI classifier step — the job's only non-success step — with The process '/usr/bin/git' failed with exit code 128.
• Test (ubuntu-latest, Node 22.x) failed in its Checkout step, after three attempts, with fatal: unable to access 'https://github.com/QwenLM/qwen-code/': Failed to connect to github.com port 443 after 134983 ms: Couldn't connect to server. The test step never started.

A two-file change under packages/cli/src/utils/housekeeping/ cannot make a self-hosted runner unable to reach github.com:443. I reached that call from the failing step identities and the git/network error text — both runner-generated — not from anything in the log body.

But "infra noise" is not the same as "evidence exists", and that distinction decides the verdict here. The one job that would have executed this PR's two new tests died before running a single one, and the macOS and Windows Test matrices are skipped on this PR. So no platform, in CI, has ever run creates the lock directory when it does not exist yet or never asks for a recursive mkdir. What did pass is real and worth having — Lint & Static (so typecheck and ESLint are clean on the changed file), Integration Tests (no-AK, No Sandbox), the OpenTUI no-flicker gate, both Desktop Shell jobs, and TUI parity snapshots — but none of those touch throttledOnce. The new tests are currently unexecuted anywhere except the author's own machine.

Not verified, and stated plainly:

• The two new unit tests have no CI result. The Linux job failed at Checkout; macOS/Windows are skipped. The only numbers that exist for them are the author's (throttledOnce.test.ts 13 passed, housekeeping surface 80 passed, on macOS) — the author's claim, not evidence, and not re-run here.
• The bind-mount reproduction is the author's evidence, not independently re-run. The before/after numbers (recursive still pending at 6s / 103% CPU vs. single-level ENOENT at 0%), the strace signature, and the fleet measurements (177 processes, ~2.5k failing mkdir/s, load average 213 → 12) all come from the PR description. Reproducing them needs root and a mount namespace, and this run neither executes PR-derived code nor has that environment.
• Windows is untested — the author marks it ⚠️ and reasons the failure mode is Linux-bind-mount specific while the change itself is platform-neutral. That reasoning looks sound (mkdir without recursive is not a platform-specific API), and with the Windows Test matrix skipped nothing here confirms it either way.
• The author's own open question stays open: why the same never-settling call presents as a hot mkdir loop in some processes and a quiet hang with no mkdir syscalls in others. The PR removes both variants either way, so this doesn't block the change — but it's an honest unknown, correctly labelled as one rather than explained away.

Sandboxed verification would settle the one claim that currently rests on the author's word: @qwen-code /verify — that mkdir(..., { recursive: true }) genuinely fails to settle on a mountpoint whose source was deleted, and that removing the option makes it reject fast, A/B against the base build. This PR's own suite pins the invariant (no mkdir call asks for recursive: true) but not the mechanism that makes the invariant matter, and a mount-namespace repro is exactly the kind of thing static review cannot substitute for. It would also, incidentally, produce the first actual execution of the two new tests.

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 4d54e6a3364a462f046d424120ded6a9ba18f667 · re-run with @qwen-code /triage}

Confidence: 3/5 — I'm confident in the code and would merge it as written; what I can't do is approve against a commit where the only job that would have run this PR's two new tests died at Checkout and never executed a single one. That's a CI re-run, not an author change.

Stepping back over the whole picture: this is what a well-formed small fix looks like. I wrote down my own proposal from the title and the "Why it's needed" section before reading the diff, and the PR landed on exactly it — drop recursive: true so the call fails fast instead of retrying forever. The two alternatives I considered are both worse, and worth saying why: a timeout around the mkdir lets the awaiting chain move on but can't cancel the retry loop Node is already running, so the CPU cost that turned this into an incident would likely survive it; pre-statting the parent adds code without removing the unbounded retry at all. One line removes both symptoms. There's nothing to cut here — no drive-by refactor, no formatting churn, no scope creep, and the 38 lines of test are proportionate to a change whose whole point is an invariant that's easy to accidentally undo.

What I'd have wanted to check going in was whether "one level is enough" was actually true, because that's the single assumption the fix rests on, and it's the kind of claim that reads plausible in a PR description and turns out to have a fourth call site nobody remembered. It holds. All three call sites put lockPath directly in the global qwen dir — including the two that hash a key into the marker filename, which was the plausible place for a hidden extra directory level and isn't. I also followed the throw path when the mkdir does fail, on both schedulers, and both catch it and reschedule, so the change converts a hang into the graceful skip it claims to produce rather than into a new crash.

On the problem itself: this is about as far from theoretical hardening as a fix: PR gets. There's a production incident with fleet-level measurements, an strace signature from a live wedged process, a self-contained reproduction, and a cross-reference to #11264 that I verified is real, open, and genuinely the complementary half rather than a duplicate. The author also flags their own unresolved question — why the same never-settling promise spins a core in some processes and hangs quietly in others — instead of papering over it with a confident-sounding explanation. That's the opposite of the pattern this gate exists to catch, and it made me trust the rest of the description more, not less.

So why not approve. Two reasons, and they're different in kind:

• The test evidence doesn't exist yet. Test (ubuntu-latest, Node 22.x) failed in its Checkout step — Failed to connect to github.com port 443 after ~135s, three attempts — so the test step never started. macOS and Windows Test matrices are skipped on this PR. That means creates the lock directory when it does not exist yet and never asks for a recursive mkdir have never run in CI on any platform. Everything else is green and some of it is meaningful (Lint & Static clears typecheck and ESLint on the changed file; integration tests, both Desktop Shell jobs, the OpenTUI gate and TUI parity all pass), but none of it executes throttledOnce. Approving now would attest to a unit-test result that does not exist, which is the exact thing I shouldn't do — and "the red is infra noise" explains why the evidence is missing without supplying it.
• Both red checks are genuinely not this PR's fault, and I want to be explicit that I'm not asking the author to fix anything. Classify PR failed in Checkout trusted CI classifier with git exit 128; the unit job failed reaching github.com:443. A two-file change under packages/cli/src/utils/housekeeping/ cannot cause either. I judged that from the failing step identities and the git/network error text, both runner-generated — not from claims in the log body.

⏸️ Deferring, not requesting changes. What this needs is a re-run of the Test (ubuntu-latest, Node 22.x) job on this same commit. Once that job goes green on 4d54e6a3364a462f046d424120ded6a9ba18f667, this is approvable exactly as it stands — I would not ask for a single code change, and re-running /triage at that point should approve it.

No approval marker is attached to this comment: the PR's own CI workflow runs have all completed (PENDING = 0), so there is nothing left for a finalize job to wait on — the missing evidence has to come from a human re-triggering the failed job.

I'm also posting this without an @mention, which I'd normally avoid on a defer. The maintainer resolver found nobody accountable to hand this to: the PR carries no labels, so no area owner matched, there's no prior human reviewer to fall back to, and no maintainer handle is configured in this run. Flagging it here rather than guessing a login. Whoever picks it up: the ask is one re-run, not a review.

One optional, non-blocking follow-up for the author, already detailed above: the Risk section frames "a lockPath whose parent doesn't exist" as a hypothetical future caller, but QWEN_HOME makes the global qwen dir's own parent arbitrary today, so that gap is reachable now without any new call site. The behaviour is still the intended graceful skip, so this is a wording tweak to the risk note, not a code change — worth a sentence so the next reader doesn't have to rediscover it.

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 4d54e6a3364a462f046d424120ded6a9ba18f667 · re-run with @qwen-code /triage}

@qwen-code /takeover

🤝 Takeover engaged: the autofix loop now manages this PR — it will address new review feedback and resolve base conflicts until the label is removed or the round cap is reached. This is a fork PR, so the first round comes from the next scheduled scan (usually within minutes). Remove the autofix/takeover label (or comment @qwen-code /takeover stop) to release.

✅ AutoFix round 1 finished — view run. See this round's report below.

Local runtime verification

I built both arms and ran this against a real deleted bind mount instead of reading the diff. Verdict: merge as it stands — every claim in the description reproduces, the two unit tests CI never got to run pass on Linux and have teeth, the ⚠️ Windows row is now measured, and the one question the description leaves open has a concrete answer. One out-of-scope follow-up is worth filing separately.

Harness

• Two real npm run bundle CLI builds: base 9a954b4198 (the PR parent) and head 4d54e6a336. The bundled runThrottledOnce differs between them at exactly one call and nothing else:

  -  await mkdir(dirname(opts.lockPath), { recursive: true, mode: 448 }).catch(() => {});
  +  await mkdir(dirname(opts.lockPath), { mode: 448 }).catch(() => {});

• A private mount namespace (unshare -m) holding a bind mount whose source directory is deleted, as root.
• Real win32 node.exe v22.22.2 (win-x64) under Wine for the platform row.
• Stated up front: everything ran as uid 0; one code-generated web-template file was stubbed identically in both bundles (unrelated to this path, needed only to make the bundle link); the Wine probe bundles throttledOnce.ts with the debug logger shimmed; Wine is not Windows.

1. The mechanism reproduces exactly as described

recursive: true was still pending at 6 s at 94 % CPU; the single-level form rejected ENOENT in 0 ms at 0 %. The strace confirms the loop the description reasons about, verbatim: mkdir(leaf)=ENOENT → mkdir(parent)=EEXIST → statx(parent)=S_IFDIR → retry leaf, ~10k failing mkdir/s, no cap, no backoff. Two extras worth recording: fs.mkdirSync(…, { recursive: true }) wedges identically (99 % CPU, main thread), and a single wedged chain does not meaningfully starve other fs work in the process (readFile p50 × 1.3) — so the cost really is CPU, not I/O latency.

2. The real CLI in the production sequence — the decisive A/B

The incident shape is a process that started healthy and had the mount deleted underneath it, so that is what I reproduced: launch the real TUI with QWEN_HOME inside the bind mount, let it bootstrap its qwen dir, rm -rf the mount source at t+14 s, and let the housekeeping first pass fire at ~t+62 s.

Both builds in one wedged mount, sampled with top at t+90 s: 91.2 % CPU for pre-PR against 0.0 % for this PR, same instant, same mount. Full 2×2, un-instrumented, CPU consumed between t+12 s and t+120 s:

Only the (pre-PR, deleted) cell burns CPU; the fix costs nothing in the healthy cell, and the TUI is identical in both arms afterwards — no error banner, no crash. I re-ran the whole 2×2 a second time and every cell reproduced to within 0.03 s.

At syscall level over the same 50 s window: 105,390 failing mkdir and zero lock acquisitions on base, against 1 mkdir then one openat of the lock file on head. The head arm's throw lands in runPass's catch in 0.6 ms and the timer chain survives, which is exactly the graceful skip the PR claims. On base the first runThrottledOnce never returns, so the serial chain never reaches step 2 or 3 and runPass never schedules another pass — the "wedges the housekeeping chain for the life of the process" claim, observed rather than argued.

3. The two unit tests, run and mutation-tested

throttledOnce.test.ts 13/13 on Linux. Full housekeeping surface: head 78 passed / 2 failed (80), base 76 passed / 2 failed (78) — the same two failures on both arms, the cleanup.test.ts EACCES cases, which cannot fail for uid 0. Environmental, not this PR.

Mutation results — 3 of 3 targeted mutants caught, working tree restored clean after each:

The stat.mode & 0o077 assertion has teeth of its own, and the guard loop tolerates a future options-less mkdir rather than erroring on it.

4. Windows — the ⚠️ row, measured

Real win32 Node under Wine, driving each arm's compiled runThrottledOnce, with the same driver re-run natively on Linux:

win32 and linux produced identical results on both arms, marker written and no lock file leaked in every passing case. Your platform-neutrality reasoning holds up under measurement.

5. Your open question — a concrete answer

You wrote that you could not explain why the same never-settling call shows up as a hot mkdir loop in some processes and a quiet hang with no mkdir syscalls at all in others (promise pending, 0 % CPU, idle libuv workers). The CLI re-execs itself, so the pid you first reach for is not the pid running the code. One single pre-PR run in the wedged mount, observed from both vantage points at once:

launcher pid 3311163  (what ps/top/pgrep show first)    0.00s CPU / 100s    0 mkdir syscalls
re-exec'd worker 3311177 (where housekeeping runs)     46.82s CPU / 100s   26,759 mkdir in a 3s sample

I hit this myself: my first three runs reported 0.00 s CPU and zero mkdir syscalls and I was about to write up a "quiet variant" until I followed the child. That reproduces your description exactly. (A second, independent mechanism also produces it: saturate all four libuv threadpool threads and the recursive mkdir never gets a thread — verified pending at 10 s, 0 syscalls, 0 % CPU. Neither is a blocker; both disappear with this PR.)

6. On the review note about QWEN_HOME

The reachability concern raised in review does not hold in practice, and it is worth recording why rather than rewording the risk note on faith. writeOutputLanguageFile (packages/cli/src/i18n/languageUtils.ts:238) does fs.mkdirSync(dir, { recursive: true }) on the global qwen dir straight from main(), before the UI renders. Measured: QWEN_HOME=/deep/a/b/c/qwen with none of a, b, c existing is fully bootstrapped within seconds — in both interactive and -p non-interactive runs, ~60 s before the first housekeeping pass. So the dir housekeeping wants always exists by then, and your risk note is accurate as written (a statement about a hypothetical future caller). No change needed.

7. One follow-up, explicitly not this PR

If the container starts after the workspace was deleted (qwen dir never created inside the broken mount), both builds hang before rendering anything, at 100 % of one core (25.00 s CPU / 25 s wall, ~59k failing mkdir/s on the main thread). Tapping fs.mkdirSync via --require and reading the stack pins it to the same writeOutputLanguageFile call above; dist-patching installationManager.writeInstallationIdToFile and saveSettings to non-recursive did not stop the spin, because languageUtils gets there first. Both arms are identical here, so this is neither caused nor claimed by this PR — but it is the same bug class, and packages/{core,cli}/src has 226 recursive-mkdir call sites, 120 of them mkdirSync. Worth a follow-up issue (a shared "create one level, fail fast" helper), not a change here.

Not verified

macOS (the author's numbers stand unre-run); the non-interactive scheduler's degradation path (read only — the interactive one is measured end to end); the fleet-level incident figures (177 processes, 45 CPU-hours, load average 213 → 12); Windows only through Wine, not on a real Windows host.

launcher pid 3311163（ps/top/pgrep 首先给你的）      100 秒内 CPU 0.00s      mkdir 系统调用 0 次
re-exec 出来的 worker 3311177（housekeeping 在此）  100 秒内 CPU 46.82s     3 秒采样 26,759 次 mkdir

🤖 Addressed the latest review feedback (round 1/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 1/100 轮）。改动内容与我反驳保留之处如下：

Autofix round — PR #11285

Commit: 51c94b68ed test(cli): guard win32 mode assertion and pin ENOENT effect in throttledOnce (1 file, +27/−1, test-only).

Feedback dispositions

rc:3948439991 + rc:3948855419 — [Critical] R1-1: unguarded permission-bit assertion fails on the Windows lane — RESOLVED

Verified the claim against in-repo evidence before editing (no win32 runner exists here either, so this mirrors the reviewer's settling authorities):

• test_windows (.github/workflows/ci.yml:1641) runs npm run test:ci and is gated on merge_group || schedule || workflow_dispatch — not pull_request — so this PR's own CI stays green and the lane goes red in the merge queue/nightly, exactly as the finding describes.
• packages/cli/package.json maps test:ci to vitest run, and packages/cli/vitest.config.ts excludes only node_modules/dist/cypress — so throttledOnce.test.ts runs on that lane.
• Every pre-existing lane-reaching assertion of this shape is guarded: packages/core/src/config/storage.test.ts:770, packages/cli/src/serve/conversations/conversation-workspace.test.ts:110, packages/cli/src/serve/managed-scratch-workspace.test.ts:75 — each wraps mode & 0o077 in if (process.platform !== 'win32') with the same libuv rationale. This diff added the first unguarded one.

Fix: wrapped only the expect(stat.mode & 0o077).toBe(0) assertion in if (process.platform !== 'win32'), keeping the umask-proof comment and adding the libuv rationale, per the storage.test.ts precedent. The guard was deliberately NOT widened to it.skipIf over the whole case, so expect(stat.isDirectory()).toBe(true) and expect(result).toEqual({ status: 'completed' }) keep witnessing a one-level mkdir on Windows.

rc:3948440012 + rc:3948855430 — [Suggestion] R1-2: pin the effect of a never-creatable lock dir, not just the mkdir options — RESOLVED

Added surfaces ENOENT instead of bootstrapping a missing parent beside the two new tests. It uses the real filesystem (the file's vi.mock('node:fs/promises', { spy: true }) is call-through; nothing is stubbed), points lockPath at a directory whose own parent does not exist, and pins a rejection with code: 'ENOENT' plus task never called. The existing option-shape test never asks for a recursive mkdir is kept untouched — the two pin different regressions.

One deviation from the reviewer's literal snippet, forced by physics: the round-1 code block placed the lockPath ONE level below tempDir (tempDir/nope/.marker.lock), but the non-recursive mkdir(tempDir/nope) succeeds when tempDir exists, so that shape resolves completed instead of rejecting — inconsistent with the finding's own witness ("PRISTINE: REJECTED code=ENOENT"). The round-2 text describes the probe as "lockPath two levels below tempDir", which is what I implemented (tempDir/nope/nested/.marker.lock) and measured locally on Node v22: one-level mkdir RESOLVED, two-level mkdir REJECTED ENOENT, two-level recursive mkdir RESOLVED, open in a missing dir REJECTED ENOENT.

Failed check: Classify PR — not addressable from this PR

classify_pr (.github/workflows/ci.yml:107) is CI routing/classification machinery (release-sync detection, runner picking, CI profile) with continue-on-error: true. Its failure cannot be caused by this PR's two-file change, the fix would live in .github/ which is outside what this round may touch, and I have no GitHub credentials to read its logs. Left for the maintainers; flagged here so it is not silently dropped.

Reviewer's self-deferred probes in rv:5130934729 — left deferred, deliberately

throttledOnce.ts:62 comment's $HOME premise under QWEN_HOME, and throttledOnce.ts:63 swallowed mkdir error never logged. The reviewer itself recorded these as "Deferred under the convergence posture (round 2, not a blocker) — recorded, not requested in this round", so they live in the review ledger and will resurface when the posture lifts. Neither is a correctness defect; touching them unrequested would grow the diff against this window's minimal-fix guidance. Not silently dropped — stated here explicitly.

Mutation probes (each run, then restored; suite re-confirmed green after restore)

• Guard-not-inert (R1-1's request): dropped mode: 0o700 from the mkdir at throttledOnce.ts:63 → creates the lock directory when it does not exist yet went RED (umask 022 → 0o755 & 0o077 = 0o055), 13 others passed. Restored.
• MUTANT B (R1-2's request): relaxed tryAcquire's throw e to return false for non-EEXIST → surfaces ENOENT instead of bootstrapping a missing parent went RED (resolves { status: 'locked' } instead of rejecting ENOENT) while the other 13 stayed green — exactly the hole the finding identified. Restored.
• MUTANT C: restored recursive: true at throttledOnce.ts:63 → both never asks for a recursive mkdir and the new effect test went RED (recursive mkdir bootstraps the parent, so the run resolves completed), 12 others passed. This is the parent-bootstrapping reroute measured through Node's own recursive mkdir. Restored.

Verification

• npm run build — passed
• npm run typecheck — passed
• npm run lint — passed
• cd packages/cli && npx vitest run src/utils/housekeeping/throttledOnce.test.ts — 14 passed (13 pre-existing + 1 new)
• cd packages/cli && npx vitest run src/utils/housekeeping/ — 41 passed, 2 files (throttledOnce + scheduler)

Settings schema untouched (no settings source changed); integration tests not applicable (behavior is fully exercised by unit tests; no bundled-CLI-only surface).

🦷 Gate advisory — this round resolves a Critical/Request-changes finding with test-only changes (machine-measured): the bite check cannot verify a test-side fix, so the resolution rests on the round summary alone. · 本轮以纯测试改动解决 Critical/Request-changes 反馈（门自动测量）：bite 检查无法验证测试侧修复，该解决仅以轮次摘要为凭。

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

🧵 Resolved all 4 selected review thread(s). · 已关闭全部选中的 4 条评审线程。

Re-review when you have a moment. After round 100 this bot stops and leaves the PR for a human. · 有空请复审；第 100 轮后本 bot 停止并将 PR 交给人工。

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.23.0

Released in v0.23.1.